貝老闆（週六早上打爆群組）：小可小可，本週末再順便加個「促銷倒數＋優惠碼＋抽獎輪盤」，很快啦！

小可（揉太陽穴，打開 Jira）：收到。已開 Ticket【WTF‑214 假日促銷】，我先填背景、範圍、風險，列三條 AC。然後請 AI 實習生先幫我們寫 CR＋PRD＋測試清單，然後再給你 Review。

貝老闆：欸欸，我是說現在就上線耶！那 AI 不能先改嗎？

小可：現在先讓 AI 交作業，我們當 Reviewer。通過 DoR 才排進 Sprint。

好威（電話那頭慢條斯理）：不愧是認真的小可，看樣子假日有去上三叔公的公開班～妳甚至已經開始觸碰到 Context Engineering 的概念。先：Ticket‑first → Doc Review → Slice → Feature Flag。把「再順便」變成有紀錄的變更，AI 先出 PRD／AC／風險矩陣，過審才動碼。

貝老闆：那這週末能上什麼？

好威： 問你家 AI 啊，請他給你建議啊....

AI 實習生：三個方案——A：極小可上線版，只上倒數 Banner＋追蹤事件，優惠碼與輪盤都掛 Flag、預設關閉；B：完整優惠碼流程，但灰度 10％；C：全餐下週。選一個方案，然後送出 CR。

貝老闆（吸一口氣）：選 A。先有聲量就好，其他下週。

小可（邊打字邊點頭）：CR 已送審；AI 實習生 請根據 Ticket 產出：User Story、AC、測試案例、Flag 策略與回滾步驟，格式用我們的模板。送來給我們審。

好威：假日也可以上，但流程要當壞人，AI 是實習生，不是你肚子裡的蛔蟲。先開票、寫 AC，讓它照票做，你當 Reviewer，不要當受害者。

好威解析

「Scope Creep 就像吃到飽餐廳邊走邊加菜，最後盤子端不起來還灑滿地。」專案的容量是固定的：人天、測試窗、上線風險都算在裡面。臨時插單不是不能做，而是要換位——拿掉不急的、或切成最小可上線的薄片版本。把需求寫進 Backlog，讓機器與流程當壞人，人只要照表操課。

概念拆解

1）什麼是 Scope Creep，怎麼擋？ 任何超出已同意範圍的額外需求、變更或細節追加，都算 Scope Creep。它常發生在商務熱情高漲、決策者混用 Demo 與上線標準的時候。解法是設「需求凍結窗」與「變更管制」（Change Request）。先把插單寫成 CR：為何必要、影響哪些模組、成本與風險、替代方案與回滾。AI 用法：請 AI 依模板生成 CR、列出受影響清單（金流、優惠碼、追蹤、客服、法遵）、產出風險矩陣與備選路線。

2）Backlog 管理與切片 先把促銷拆成 Epic／Story／Task，例如：A 倒數 Banner、B 優惠碼驗證、C 結帳折抵、D 事件追蹤、E 兌獎頁。用 MoSCoW 或 RICE 排優先，設定 WIP 上限與 Sprint 容量，非必需就延後。用 Feature Flag 控制曝光，允許灰度與快速關閉。AI 用法：請 AI 產生 User Story 與 Acceptance Criteria、測試案例樣板與旗標策略，順便輸出 Release 計畫與 Rollback 清單。

3）Definition of Ready／Definition of Done DoR 檢核：用戶價值說清楚、AC 明確可驗收、資料與權限到位、風險與依賴列出、Owner 與估點完成；不達標不入 Sprint，套用新的概念就是不給 AI 做。DoD 檢核：程式碼審查、單元／整合測試過關、監控與告警設定、回滾步驟、文件與客服話術同步。AI 用法：把故事丟給 AI 做 DoR／DoD 自動勾稽，請它產出缺漏清單與建議範例。

4）假日上線生存手冊 假日要上線就要更保守：凍結非必要變更、準備 on-call 名單與時段、預先演練回滾腳本、設 Kill‑Switch、金流走沙箱重演、監控看得到轉換率與錯誤率。AI 用法：請 AI 生成 Runbook、事故回報模板（包含 TTR／影響面）、模擬異常情境與合成測試資料，確保一鍵回滾。

5）與老闆的容量談判術 用「容量比喻」說人話：這台卡車一次只能載 10 箱，你要再加 5 箱就要拿掉 5 箱、或改兩趟。提供三個選項：A 極小可上線版今週末可推；B 全餐版下週上；C 取消本檔期。給出數據化影響（轉換率、風險成本、客服負荷）。AI 用法：請 AI 產生對外公告、FAQ、客服話術，以及 AB 測試計畫與實驗假設。

Context Engineering：把 AI 納入「人類流程」

• 對 AI 開票（Ticket‑first）：所有插單都變一張 Issue，必填：背景與目標（Why）、範圍（Scope／Out‑of‑Scope）、預期產物（Artifacts：PRD／Wireframe／ADR／Test Plan）、限制（法遵／金流）、驗收條件（AC）、時間箱（Timebox）。
• 上下文工程（Context Engineering）：在票內嵌入給 AI 的「五件組」——角色（Role）、專案脈絡（Context／現有架構與邊界）、資料來源（Links／Examples）、禁止清單（Guardrails：不可改動區塊、不可觸碰金流密鑰）、輸出格式（Output Schema：MD／JSON／表格）。AI 的輸出才能穩定且可審。
• 先文後碼（Docs‑before‑Code）：第一迭代只讓 AI 產出 PRD、AC、測試清單、API 規格與風險評估，交給人審（Doc Review）。通過再讓 AI 進行最小單元的實作。
• 小步上線（Slice‑and‑Flag）：AI 只推 Feature Branch，所有變更掛 Ticket ID，PR 描述需包含風險、回滾、監控點；以 Feature Flag 控制曝光，灰度或暗流量先跑。
• 防亂改（Guarded CI）：CI 內建 Lint、Unit、Integration、Contract、金流沙箱、Screenshot Diff；任一失敗即退回，避免「AI 亂改」直達產線。

下面就是簡單範例，把所有的票都以資料夾和文件的方式存放

Takeaways

• 沒有 Backlog 的邊界，任何「順便」都是炸彈。 用 CR＋優先級＋容量化把情緒變決策。
• DoR／DoD 是專案的安全帽。 戴上它，再談速度與創意。
• Feature Flag＋灰度＝假日求生包。 能收能放，才敢推廣告與促銷。
• Context Engineering 跟AI 協作更需要清楚的流程和文件

今日提問

1）你們團隊現在有沒有「需求凍結窗」與「變更管制」？若沒有，最小可以先做哪一步？
2）把這次最想做的促銷拆成 3 個最小故事，哪一個今天上線就能創造 80% 效益？

小作業（可直接丟給 AI 的 Prompt）

「請扮演資Product Owner。根據以下促銷需求說明，幫我輸出：1）Change Request（目的、影響模組、風險矩陣、替代方案、回滾步驟）；2）按 MoSCoW 排序的 User Stories（每則含 Acceptance Criteria、測試案例）；3）Feature Flag 策略（開關條件、灰度、Kill‑Switch）；4）Release 與 Rollback 計畫；5）對外公告與客服 FAQ。需求如下：〈把你的促銷描述貼上〉。」

附錄｜文件樣板（可直接複製給 AI）

A. Change Request（CR）模板

# Change Request：<促銷主題>
- 背景／目標（Why）：
- 範圍（Scope／Out of Scope）：
- 影響模組（Impact）：金流｜優惠碼｜追蹤｜UI｜客服｜法遵｜資料
- 風險矩陣（Risk x Likelihood x Impact）：
- 替代方案（Plan B／C）：
- 監控與量測（Metrics）：錯誤率、轉換率、退款率、客服量
- 回滾策略（Rollback）：Flag 關閉／版本回退步驟
- 時間箱與責任人（Timebox／Owner）：

B. User Story ＋ AC 樣板（Gherkin）

User Story：
As a 買家，我想在結帳輸入優惠碼，讓我在本檔期享有折扣。

Acceptance Criteria：
Scenario: 有效優惠碼折抵
  Given 我在結帳頁且登入狀態
  And 購物車滿 NT$1,000
  When 我輸入有效優惠碼「WEEKEND20」並按套用
  Then 顯示折抵 NT$200 並更新應付金額
  And 事件被送到 GA4 與後端日誌

Scenario: 無效或過期
  When 我輸入過期碼
  Then 顯示「已過期」且不變更金額

C. DoR／DoD 勾稽清單

DoR：
[ ] 目標與用戶價值清楚  [ ] AC 明確可驗收  [ ] 依賴／風險列出
[ ] 權限與資料到位      [ ] 工期估點完成      [ ] 監控指標定義

DoD：
[ ] Code Review 通過     [ ] 單元／整合／合約測試綠燈
[ ] 監控與告警上線       [ ] 回滾腳本驗證       [ ] 文件與客服話術更新
[ ] Feature Flag／Kill‑Switch 可用